home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-dns-idpr-00.txt < prev    next >
Encoding:
Text File  |  1993-03-23  |  6.0 KB  |  162 lines
  1.  
  2.  
  3.                         INTERNET DRAFT
  4.                      DNS Support for IDPR
  5.  
  6.                        22 March 1993
  7.  
  8.                          Rob Austein
  9.                Epilogue Technology Corporation
  10.                        sra@epilogue.com
  11.  
  12.  
  13. Status of this Memo
  14.  
  15. This document is an Internet Draft.  Internet Drafts are working
  16. documents of the Internet Engineering Task Force (IETF), its Areas,
  17. and its Working Groups.  Note that other groups may also distribute
  18. working documents as Internet Drafts.
  19.  
  20. Internet Drafts are draft documents valid for a maximum of six months.
  21. Internet Drafts may be updated, replaced, or obsoleted by other
  22. documents at any time.  It is not appropriate to use Internet Drafts
  23. as reference material or to cite them other than as a "working draft"
  24. or "work in progress."  Please check the 1id-abstracts.txt listing
  25. contained in the internet-drafts Shadow Directories on nic.ddn.mil,
  26. nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to
  27. learn the current status of any Internet Draft.
  28.  
  29. This is a working document only, it should neither be cited nor quoted
  30. in any formal document.
  31.  
  32. This document will expire before 09-22-1993..
  33.  
  34. Distribution of this document is unlimited.
  35.  
  36. Please send comments to the author.
  37.  
  38.  
  39. 1.  Introduction
  40.  
  41. This note documents the support needed from the Domain Name System
  42. (DNS) by Inter-Domain Policy Routing (IDPR).  The DNS changes are
  43. minor and can be deployed with minimal impact on the installed DNS
  44. community.
  45.  
  46. When an IDPR Policy Gateway receives an IP packet, it needs to map the
  47. packet's IP address to an IDPR Administrative Domain (AD) in order to
  48. deliver the packet.  The initial prototype implementation of IDPR used
  49. a configuration file to provide this mapping, but this is clearly
  50. unacceptable for a full-scale deployment of IDPR.  As an existing,
  51. well understood, (relatively) low-overhead distributed database, the
  52. DNS is the obvious mechanism by which to distribute these mappings.
  53.  
  54. Due to an unfortunate collision in use of the term "domain" by both
  55. IDPR and the DNS, this note avoids unqualified use of the term
  56. "domain."
  57.  
  58.  
  59. 2. The AD RR type.
  60.  
  61. We define one new DNS RR type, with symbolic name "AD" and numeric
  62. value xxx.  This RR type is class-independent; the rest of this note
  63. discusses IN class AD RRs, with the understanding that the mechanism
  64. described here is not tied to IP addresses.  The RDATA portion of an
  65. AD RR consists of two 32-bit integers, each representing an IDPR AD.
  66. The two fields are the "home" AD associated with the address, and the
  67. proxy AD associated with the address.  An AD which is acting as its
  68. own proxy (the normal case) has the same value for these two fields.
  69.  
  70. Class IN AD RRs appear in the IN-ADDR.ARPA portion of the DNS name
  71. space.  These RRs are used to map from an IP address to an IDPR AD.
  72. We expect that it will be possible to make heavy use of "wildcard" DNS
  73. names here, since we expect that all the hosts on a given IP network
  74. (or subnetwork) are likely to belong to a single IDPR AD.
  75.  
  76. For purposes of discussion, assume that Miskatonic University is in
  77. Administrative Domain 42, while Engulf & Devour, Inc., is in
  78. Administrative Domains 666 and 17; Engulf & Devour recently purchased
  79. Liver Donors Ltd., in order to use their Policy Gateway as a proxy for
  80. Engulf & Devour's corporate network.  The following RRs might appear
  81. in the DNS:
  82.  
  83.         Loki.Miskatonic.EDU.   IN A 1.1.1.5
  84.         Thor.Miskatonic.EDU.   IN A 1.1.1.6
  85.         Liver-Donors.EaD.COM.  IN A 2.2.2.7
  86.         HQ.EaD.COM.            IN A 3.3.3.8
  87.  
  88.         5.1.1.1.IN-ADDR.ARPA.  IN PTR   Loki.Miskatonic.EDU.
  89.         5.1.1.1.IN-ADDR.ARPA.  IN AD    42  42
  90.         6.1.1.1.IN-ADDR.ARPA.  IN PTR   Thor.Miskatonic.EDU.
  91.         6.1.1.1.IN-ADDR.ARPA.  IN AD    42  42
  92.         7.2.2.2.IN-ADDR.ARPA.  IN PTR   Liver-Donors.EaD.COM.
  93.         7.2.2.2.IN-ADDR.ARPA.  IN AD    666 666
  94.         8.3.3.3.IN-ADDR.ARPA.  IN PTR   HQ.EaD.COM.
  95.         8.3.3.3.IN-ADDR.ARPA.  IN AD    17  666
  96.  
  97.  
  98. In this case the AD RRs for Miskatonic University could usefully be
  99. collapsed into a wildcard RR:
  100.  
  101.         *.1.1.1.IN-ADDR.ARPA.  IN AD    42  42
  102.  
  103.  
  104. 3. Use of the AD RR type.
  105.  
  106. In the initial deployment of of IDPR, we believe that only IDPR Policy
  107. Gateways will need to know about IDPR ADs.  Thus, only Policy Gateways
  108. will need to obtain and use AD RRs.  In the long run it may be
  109. beneficial for hosts to obtain this data as well, but it is not
  110. necessary that they do so in order for IDPR to work correctly.
  111.  
  112.  
  113. 4. Bootstrapping the Policy Gateways
  114.  
  115. Since a Policy Gateway needs an AD before it can forward a packet, the
  116. AD associated with the IP addresses of each of the Policy Gateway's
  117. default DNS name servers needs to be part of the Policy Gateway's
  118. configuration.  Ie, there is a bootstrapping problem here, because we
  119. can't use the DNS to obtain the ADs we need in order to talk to the
  120. DNS.  Note that the Policy Gateway's default DNS name servers are not
  121. necessarily the root DNS name servers; indeed, clever use of
  122. centralized DNS caches by a community of Policy Gateways will help
  123. decrease the load IDPR will add to the existing DNS system.
  124. Ultimately, however, this question reduces to the question of how the
  125. Policy Gateways reach the DNS root servers.
  126.  
  127.  
  128. 5. Glue RRs
  129.  
  130. Since in some cases the authoritative nameservers for a particular AD
  131. RR may be within the AD itself, it may be necessary to insert "glue"
  132. AD RRs into some zones in the IN-ADDR.ARPA tree.  These fill the same
  133. role as the glue A RRs already in use to solve the analogous problem
  134. with finding the IP address of a name server.
  135.  
  136.  
  137. 6. Acknowledgments
  138.  
  139. Most of the ideas in this document were derived from email
  140. conversations with Martha Steenstrup and Robert Woodburn, without
  141. whose help the author would still be completely clueless about IDPR
  142. and its requirements.
  143.  
  144.  
  145. 7. Author's address:
  146.  
  147.         Rob Austein
  148.         Epilogue Technology Corporation
  149.         268 Main Street, Suite 283
  150.         North Reading, MA 01864
  151.  
  152.         <sra@epilogue.com>
  153.  
  154.  
  155. 8. References
  156.  
  157. [1]  IDPR specifications, currently another Internet Draft.
  158.  
  159. [2]  DNS specifications, RFCs 1034 & 1035.
  160.  
  161. [3]  DNS administrators guide, RFC 1033.
  162.